Cross-layer context management

ABSTRACT

In peer-to-peer (P2P) communications, it has been recognized herein that various context information needs to be exchanged between peer devices (PDs) or between different layers/protocols within a peer device (PD). Various embodiments described herein address how to design effective management functions, services, and primitives for context management across and/or within different protocol layers to enable context-aware peer-to-peer communications in proximity. This disclosure proposes multiple embodiments for cross-layer context management in context-aware peer-to-peer communication in proximity. For example, embodiments described herein provide context management to efficiently enable context-aware P2P communications, such as, for example, social networks.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 61/951,041 filed Mar. 11, 2014 the disclosure ofwhich is hereby incorporated by reference as if set forth in itsentirety herein.

BACKGROUND

Referring to FIG. 1, an example architecture 100 is shown. Thearchitecture 100 conforms to an IEEE 802.15.4-2012 reference model or anLR-WPAN device architecture. The architecture 100 includes a physical(PHY) layer 102, a medium access control (MAC) layer 104, and upperlayers 106. Upper layers may also be referred to herein as higher orhigh layers 106. Aspects of the architecture 100 are further describedin IEEE Std 802.15.4-2012, “Part 15.4: Wireless Medium Access Control(MAC) and Physical Layer (PHY) Specifications for Low-Rate WirelessPersonal Area Networks (WPANs),” which is incorporated by reference asif set forth in its entirety herein, and which is referred to herein asIEEE 802.15.4-2012. As shown, the architecture 100 includes four ServiceAccess Points (SAPs) that have been defined for interactions between twolayers. Specifically, the illustrated architecture 100 includes 1) a MACCommon Part Sublayer (MCPS) SAP 108 for data plane interactions betweenupper layers 106 and the MAC layer 104; 2) a MAC SubLayer ManagementEntity (MLME) SAP 110 for management plane interactions between upperlayers 106 and the MAC layer 104; 3) a PD SAP 112 for data planeinteractions between the MAC layer 104 and the PHY layer 102; and 4) aPhysical Layer Management Entity (PLME) SAP 114 for management planeinteractions between the MAC layer 104 and the PHY layer 102.

In IEEE 802.15.4-2012, service primitives are defined to realize aservice, for example, by interacting between two protocol layers.Referring to FIG. 2, a primitive model 200 is shown as defined by IEEE.The primitive model 200 includes a first device 201 a and a seconddevice 201 b. The first device 201 a in the primitive model 200 makes arequest, and thus the first device 201 a can also be referred to as aRequestor 201 a. The second device 201 b in the primitive model 200receives the request, and thus the second device 201 b can also bereferred to as a Recipient 201 b. In accordance with the illustratedprimitive model 200, one “Request” primitive 202 can result in: one“Confirm” primitive 204 at the same device (e.g., Requester 201 a); andan “Indication” primitive 206 and a “Response” primitive 208 at theother device (e.g., Recipient 201 b). The model 200 is referred toherein as a one-to-one primitive model. Still referring to FIG. 2, inaccordance with the illustrated example, the request primitive 202 isused to request that a service is initiated. The indication primitive206 is used to indicate an external event to the user of the seconddevice 201 b. The response primitive 208 is used to complete a procedurepreviously invoked by the indication primitive 206. The confirmprimitive 204 is used to convey the results of one or more associatedprevious service requests.

IEEE 802.15.4-2012, which is incorporated by reference as if thedisclosure of which is set forth in its entirety herein, defines thefollowing types of services, and each type is realized via certainprimitives: 1) MAC management service, which is realized via MLME SAPprimitives; 2) MAC data service, which is realized via MCPS SAPprimitives; 3) PHY management service, which is realized via PLME SAPprimitives; and 4) PHY data service, which is realized via PD SAPprimitives.

Table 1 below shows example MLME-SAP primitives that are specified inIEEE 802.15.4-2012, and Table 2 below shows example MCPS-SAP primitivesthat are specified in IEEE 802.15.4-2012.

TABLE 1 Primitive Name Description Request Indication Response ConfirmMLME- Used for a device to ✓ ✓ ✓ ✓ ASSOCIATE associate with a WPAN MLME-Used for a device to de- ✓ ✓ ✓ DISASSOCIATE associate with a WPAN MLME-To notify upper layer of a ✓ BEACON- received beacon NOTIFY MLME-COMM-To allow the MLME to ✓ STATUS indicate a communications status MLME-GETTo request information ✓ ✓ about a given PIB attribute MLME-GTS Torequest and maintain ✓ ✓ ✓ GTSs MLME- Used by a coordinator to ✓ ✓ORPHAN issue a notification of an orphaned device MLME-RESET To resetMAC sublayer ✓ ✓ MLME-RX- To enable or disable a ✓ ✓ ENABLE device'sreceiver at a given time MLME-SCAN To either find PANs in a ✓ ✓ channelor measure the energy in the channel MLME-SET To write PIB attributes ✓✓ MLME-START Used by an FFD to initiate a ✓ ✓ PAN, to begin using a newsuperframe configuration, or to stop transmitting beacons. In addition,a device uses these primitives to begin using a new superframeconfiguration MLME-SYNC To synchronize with a ✓ ✓ coordinator and tocommunicate loss of synchronization to the next higher layer MLME-SYNC-To indicate the loss of ✓ LOSS synchronization with the coordinator tothe next higher layer MLME-POLL To request data from the ✓ ✓ coordinatorMLME-DPS Used by a device to enable ✓ ✓ ✓ or disable dynamic preambleselection (DPS) as well as to define the value of dynamic preamble fortransmission and reception for a given time (only for UWB PHY) MLME- Toobtain the results of a ✓ ✓ SOUNDING channel sounding from anRanging-capable Device (RDEV) that supports the optional soundingcapability MLME- To obtain the results of a ✓ ✓ CALIBRATE rangingcalibration request from an RDEV

TABLE 2 Primitive Name Description Request Indication Response ConfirmMCPS-DATA Used for a device to associate ✓ ✓ ✓ with a WPAN MCPS- Usedfor a device to de- ✓ ✓ PURGE associate with a WPAN

FIG. 3 shows an example reference model 300 proposed for IEEE 802.15.8.Referring to the example that is illustrated in FIG. 3, a PD ManagementEntity (PDME) 302 is defined, but it is recognized herein that currentapproaches, including the current PDME, have not addressed how toexchange various specific management information (e.g., contextinformation). Further, it is recognized herein that there are no MAC/PHYprimitives defined in the current approaches.

SUMMARY

In peer-to-peer (P2P) communications, it has been recognized herein thatvarious context information should be exchanged between peer devices(PDs) and/or between different layers/protocols within a peer device(PD). Various embodiments described herein address how to designeffective management functions, services, and primitives for contextmanagement across and/or within different protocol layers to enablecontext-aware peer-to-peer communications in proximity. This disclosureproposes multiple embodiments for cross-layer context management incontext-aware peer-to-peer communication in proximity. For example,embodiments described herein provide context management to efficientlyenable context-aware P2P communications, such as, for example, socialnetworks.

In one embodiment, at a peer device, context information is exchangedacross layers in the peer device. The context information may beexchanged via at least one service access point (SAP). For example, theat least one SAP may include a physical layer context management (PLCM)SAP, a medium access control (MAC) layer context management (MLCM) SAP,and a high layer context management (HLCM) SAP. Further, in accordancewith various example embodiments, new context management primitives andprocedures are described herein for the PLCM SAP to support measuringcontext information at the PHY layer and reporting context informationto the MAC layer. Further, new context management primitives andprocedures are described herein for the MLCM SAP to provide contextmanagement services (e.g., context retrieve, context subscription andnotification, etc.) between the MAC layer and a context manager. Furtheryet, new context management primitives and procedures for the HLCM SAPto provide context management services (e.g. context retrieve, contextsubscription and notification, etc.) between a high layer and thecontext manager

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter. Furthermore,the claimed subject matter is not limited to limitations that solve anyor all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example IEEE 802.15.4-2012 reference model orLR-WPAN device architecture;

FIG. 2 shows an example service primitive mode from IEEE 802.15.4-2012;

FIG. 3 shows an example reference model proposed for IEEE 802.15.8;

FIG. 4 is a system diagram that shows an example of social networks inproximity in accordance with an example embodiment;

FIG. 5 is a block diagram that shows a cross-layer context manager inaccordance with an example embodiment;

FIG. 6 is a block diagram that shows another cross-layer context managerin accordance with another example embodiment;

FIG. 7A is a call flow for reporting context information from a physicallayer (PHY) to a context manager (CM) in accordance with an exampleembodiment;

FIG. 7B is a call flow for enabling or disabling a context informationat the PHY in accordance with an example embodiment;

FIG. 7C is a call flow for discovering context information at the PHY inaccordance with an example embodiment;

FIGS. 8A-B is a call flow that shows an example method and exampleprimitives for reporting context information from high layer to contextmanager where the context manager is not a part of the MAC layer inaccordance with example embodiments;

FIG. 9 is a call flow that shows an example procedure and exampleprimitives for reporting context information from high layer to contextmanager where the context manager is a part of the MAC layer inaccordance with an example embodiment;

FIGS. 10A-B are call flows that show example methods and primitives fora high layer to retrieve context information in accordance with exampleembodiments;

FIGS. 11A-B are call flows that show example methods and primitives forthe high layer to delete context information in accordance with exampleembodiments;

FIGS. 12A-B are call flows that show example methods and primitives forthe high layer to subscribe to context information in accordance withexample embodiments;

FIGS. 13A-B are call flows that show example methods and primitives forthe context manager to notify context information in accordance withexample embodiments;

FIG. 14 is a call flow that shows an example method for reportingcontext information in accordance with another example embodiment;

FIG. 15 is a call flow that shows an example method for retrievingcontext information in accordance with another example embodiment;

FIG. 16 is a call flow that shows an example procedure for deletingcontext information in accordance with an example embodiment;

FIG. 17 is a call flow that shows an example procedure for subscribingto context information in accordance with an example embodiment;

FIG. 18 is a call flow that shows an example procedure for notifyingcontext information in accordance with an example embodiment;

FIG. 19 shows a service primitive model in accordance with an exampleembodiment;

FIG. 20 shows another service primitive model in accordance with anotherexample embodiment;

FIG. 21 shows an example integrated context management procedure usingcontext report for one example scenario, in accordance with anotherexample embodiment;

FIG. 22 shows an example integrated context management procedure usingcontext report for another example scenario, in accordance with yetanother example embodiment;

FIG. 23A is a system diagram of an example machine-to-machine (M2M) orInternet of Things (IoT) communication system in which one or moredisclosed embodiments may be implemented;

FIG. 23B is a system diagram of an example architecture that may be usedwithin the M2M/IoT communications system illustrated in FIG. 23A;

FIG. 23C is a system diagram of an example M2M/IoT terminal or gatewaydevice that may be used within the communications system illustrated inFIG. 23A; and

FIG. 23D is a block diagram of an example computing system in whichaspects of the communication system of FIG. 23A may be embodied.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

For convenience, some acronyms that are used in this disclosure aredescribed below:

CM Context Manager

ETSI European Telecommunications Standards Institute

HLCM High Layer Context Management

IEEE Institute of Electrical and Electronics Engineers

IoT Internet of Things

M2M Machine-to-Machine

MAC Medium Access Control

MCPS MAC Common Part Sublayer

MLCM MAC Layer Context Management

MLME MAC subLayer Management Entity

P2P Peer-to-Peer

PD Peer Device

PDME PD Management Entity

PHY Physical

PLCM PHY Layer Context Management

PLME PHY Layer Management Entity

PRL Protocol Layer

SAP Service Access Point

As used herein, the term protocol layer may refer to the PHY layer 102,the MAC layer 104, and/or upper layers 106 (e.g., layers above the MAClayer 104). It will be understood that, for convenience and clarity,reference numbers are repeated in different figures to indicate the sameor similar features. A protocol layer typically provides certainservices, which can be accessed by other protocol layers. The termService Access Point (SAP), unless otherwise specified, refers to aninterface between two neighboring (adjacent) protocol layers. Forexample, via a SAP, a protocol layer can access services provided byanother protocol layer. The term primitive, unless otherwise specified,refers to the message transmitted between two neighboring protocollayers through their SAP.

Example Context-aware primitives in a context-aware P2P architecture arespecified below in Table 3 and Table 4. The example primitives havevarious context information (e.g., application identifiers) embedded inthem, but specific primitives for supporting context management andoperations across protocols layers are not defined in Tables 3 and 4.

TABLE 3 MAC MLME Primitives for Management MLME Primitives TypeDescription MLME-CONTEXT- Request, CONTEXT exchange for Application iAPPi Confirm This enables the context exchange with higher layer for aspecific application. MLME-GENSCAN Request, GENeral SCAN initiated byhigher layer Confirm This enables the higher layer to trigger a generalpurpose scan with related context information. For example, a generalscan can be used to detect the useful peer information in proximityneeded by multiple logic functions such as peer discovery, context-awaresynchronization, channel allocation detection, context-aware powerdetection etc., especially at the beginning of establishing aninfrastructure-less P2P network. MLME-START-APPi Request, STARTApplication i Confirm This enables the higher layer to initiate a P2Pnetwork for a specific application. MLME-SYNC-APPi RequestSYNChronization for Application i This enables the higher layer todirect the Synchronization Function to synchronize with a specificapplication, especially required for supporting multiple applicationssimultaneously. MLME-SYNC-LOSS- Indication SYNChronization LOSS forApplication i APPi This enables the Synchronization Function to noticethe higher layer the loss of synchronization for a specific application.MLME-DISCOVERY- Request, DISCOVERY for Application i APPi Confirm, Thisenables the higher layer to assist peer discovery for a Indication,specific application. For example, some confirmation may be Responseneeded from the user for security and/or privacy concerns. MLME-CHANNEL-Request, CHANNEL management for Application i APPi Confirm This enablesthe higher layer to trigger channel re-allocation due to channelconditions or QoS of the service for a specific application.MLME-ASSOCIATE- Request, ASSOCIATE for Application i APPi Confirm Thisenables the higher layer to assist peer association for a Indication,specific application. For example, some confirmation may be Responseneeded from the user for security and/or privacy concerns. MLME-Request, ASSOCIATE UPDATE for Application i ASSOCIATEUPDATE- ConfirmThis enables the higher layer to trigger association update APPiIndication, for a specific application. For example, update theassociate Response due to context change, or QoS, etc. MLME- Request,DISASSOCIATE for Application i DISASSOCIATE- Confirm This enables thehigher layer to trigger disassociation for a APPi Indication, specificapplication. For example, disassociation due to Response channel status,QoS, or service policy, etc. MLME- Request, RE-ASSOCIATE for Applicationi REASSOCIATE- Indication, This enables the higher layer to triggerre-association for a APPi Response, specific application. For example,re-associate due to Confirm channel condition, QoS, or policy, etc.MLME-TX-APPi Request, Enable TX (transmitting) for Application i ConfirmThis allows the higher layer to enable the transmitting for a specificapplication. MLME-RX-APPi Request, Enable RX (receiving) for Applicationi Confirm This allows the higher layer to enable the receiving for aspecific application. MLME- Request, POWER CONTROL for Application iPOWERCONTROL- Confirm This enables the higher layer to trigger thecontext-aware APPi power control for a specific application.MLME-MEASURE- Request, MEASUREment for Application i APPi Confirm Thisenables the higher layer to trigger the measurement for a specificapplication, which may be used for cross-layer QoS management.MLME-REPORT- Request, REPORT from logic functions for Application i APPiConfirm This enables the higher layer to trigger the report function fora specific application, which may be used for cross-layer QoSmanagement. MLME-SLEEP-APPi Request, SLEEP mode for Application iConfirm, This enables the higher layer to force lower layers into sleepIndication, mode. Response MLME-WAKEUP- Request, WAKE UP from sleep modefor Application i APPi Confirm This enables the higher layer to pulllower layers out of sleep mode.

TABLE 4 MAC MCPS Primitives for Data MCPS Primitives Type DescriptionMCPS-DATA-APPi Request, DATA transmission for Application i Indication,This enables the higher layer to trigger Confirm the Data TransceivingFunction to transmit data for a specific application, which is neededfor supporting multi-application data transmitting and receiving.

In P2P communications, it has been recognized herein that variouscontext information needs to be exchanged between PDs or betweendifferent protocols within a given PD. FIGS. 4-22 (describedhereinafter) illustrate various embodiments of methods and apparatus forexchanging various context management information. In these figures,various steps or operations are shown being performed by one or morepeer devices. It is understood that the peer devices illustrated inthese figures may represent logical entities in a communication networkand may be implemented in the form of software (e.g.,computer-executable instructions) stored in a memory of, and executingon a processor of, a node of such network, which may comprise one of thegeneral architectures illustrated in FIG. 23C or 23D described below.That is, the methods illustrated in FIGS. 4-22 may be implemented in theform of software (e.g., computer-executable instructions) stored in amemory of a network node, such as for example the node or computersystem illustrated in FIG. 23C or 23D, which computer executableinstructions, when executed by a processor of the node, perform thesteps illustrated in the figures. It is also understood that anytransmitting and receiving steps illustrated in these figures may beperformed by communication circuitry (e.g., circuitry 34 or 97 of FIGS.23C and 23D, respectively) of the node under control of the processor ofthe node and the computer-executable instructions (e.g., software) thatit executes.

Referring now to FIG. 4, an example network 400 includes a plurality ofpeer devices (PDs) 201 that can communicate with each other viaproximity communications. It will be appreciated that the examplenetwork 400 is simplified to facilitate description of the disclosedsubject matter and is not intended to limit the scope of thisdisclosure. Other devices, systems, and configurations may be used toimplement the embodiments disclosed herein in addition to, or insteadof, a network such as the network 400, and all such embodiments arecontemplated as within the scope of the present disclosure. It willfurther be appreciated that reference numbers may be repeated in variousfigures to indicate the same or similar features in the figures.

Still referring to FIG. 4, during communication, a first PD, forinstance the PD 201 a, may need to indicate certain context informationto a second PD, for instance a PD 201 b. For example, the contextinformation that it is indicated at 402 may include, without limitation,a link quality associated with the PD 201 a and the PD 201 b, a physicallocation associated with the PD 201 a, a residual battery levelassociated with the PD 201 a, a user profile associated with the PD 201a, or the like. Generally, the term context information may refer toinformation that can be used to describe, track, and/or infer thesituational state or condition of a service, an application, a device, anetwork, or a combination thereof. An exchange, such as the exchange at402 for example, can be referred to as a cross-PD context exchange. Byway of example, at 404, in accordance with illustrated example, a thirdPD 201 c and a fourth PD 201 d exchange information with each other. Inan example embodiment, as described further herein, context can also beexchanged across different protocol layers within a PD. For example, asdepicted in FIG. 4, within the PD 201 d, the MAC layer 104 may obtain alink quality from the PHY layer 102 (at 406), and the high layer 106 maypass service category information to the MAC layer 104 (at 408). Anexchange, such as the example exchange at 406 and the example exchangeat 408, can be referred to as cross-layer context exchange. In anexample aspect, a cross-PD context exchange can be triggered by across-layer context change. For example, by receiving service categoryinformation from the high layer 106 (at 408), the MAC layer 104 of thePD 201 d may initiate a cross-PD context exchange to notify the PD 201 c(at 404) of the service category information associated with the PD 201d. It is recognized herein that such context management is currentlylacking, such context management may be critical to supportapplication-driven P2P communications, for instance P2P communicationsin which a peer device participates in multiple applicationssimultaneously as required by IEEE 802.15.8, referenced above.

Various embodiments described herein address various issues, forexample, such as how to design effective management functions, services,and primitives for context management across and/or within differentprotocol layers to enable context-aware peer-to-peer communications inproximity. Multiple embodiments are described herein for cross-layercontext management in context-aware peer-to-peer communications inproximity. For example, embodiments described herein provide contextmanagement to efficiently enable context-aware P2P communications, suchas, for example, social networks such as the example network 400illustrated in FIG. 4.

Presented below are detailed descriptions of various embodiments. First,example use cases that apply to context management for P2Pcommunications are introduced. Following the introduction of exampleuses cases, embodiments are described that include various new functionsand primitives for cross-layer context management.

Use Cases

In an example use case, P2P applications may be the only way to maintaincommunications among peers when network infrastructure becomes congestedor unavailable, for example due to disasters. In another example usecase, P2P communications may improve network performance (e.g., systemcapacity) by triggering and facilitating traffic offloading. P2PCommunications cover a large variety of applications that can becategorized in four general types: 1) human-to-human; 2)human-to-machine; 3) machine-to-machine (M2M); and 4) machine-to-human.

As used herein and as mentioned above, unless otherwise specified,context information (or simply context) generally refers to informationthat describes a situation or surroundings associated with a node orentity. Context information in P2P communications can be classified intothe following example classes: 1) device context that describes a deviceprofile, capability, and/or status (e.g., location, battery level,mobility, etc.); 2) network context that shows network conditions andmeasurements (e.g., link quality, congestion, bandwidth, etc.); 3) usercontext that indicates properties about a user or a group of users(e.g., gender, age, address, body conditions, shopping behavior,relationship, etc.); and 4) service context that is related tocharacteristics of services (e.g., service category, service rate, orthe like). As described herein, different protocol layers may have ormay generate different context information. For instance, the PHY layer102 and the MAC layer 104 may generate device and network context, andthe higher layers 106 may have service context and/or user context. Asused herein, the term context-awareness generally refers incorporatingcontext information into a system design to improve overall systemperformance. In other words, it is recognized herein that P2Pcommunication protocols should be aware of and should be adapted todevice/user/service/network context information. It is furtherrecognized herein that awareness of context information and adaptationto context information benefits from the design of effective contextmanagement functions and corresponding primitives across differentprotocol layers.

For example, the following context information may exist in a P2P socialnetworking application, presented by way of example and withoutlimitation: device context (e.g., battery condition, location); usercontext (e.g., user ID, user icon, user photo, user location, degree ofconnections, joined group members, etc.); network context (e.g.,activated connections, quality associated with activated connections);service context (e.g., service category to indicate social networking);application context (e.g., an application identifier such as Facebook orTwitter, a message type such as a Facebook status update, a friendshipinvitation, etc.)

Various context management functions (or services) are described herein.Such functions may benefit social network applications, among others.Examples of intra-peer context management functions, which refer tofunctions that are implemented within a peer, include, withoutlimitation: a functionality in which the higher layer 106 requests thatthe MAC layer 104 discover other peers in proximity for a networkingapplication; a functionality in which higher layers 106 request that theMAC layer 104 discover a given peer (e.g., friends) in proximity, sothat the given peer can use a networking application; and afunctionality in which the MAC layer 104 indicates to higher layers 106that new peer that are using a particular application are in proximity.Examples of inter-peer context management functions include, withoutlimitation, a functionality in which a peer indicates itsservice/application/user context to a group of other peers withinproximity; and various group based activities (e.g., group informationnotification, assignment/update of a group within a networkingapplication, etc.)

Example Embodiments

Example embodiments described herein implement various cross-layercontext management features, such as, for example and withoutlimitation: 1) context management functions; 2) context managementprimitives; 3) integrated context management procedures; and 4) a newservice primitive model.

Referring now to FIG. 5, in accordance with the illustrated embodiment,a peer device 201 includes a context manager 120 that is defined as afunction across multiple protocol layers. The context manager 120interfaces to the layers via three horizontal SAPs. As shown, thecontext manager 120 interacts with the high layers 106 via a higherlayer context manager (HLCM) service access point 122. As further shown,the context manger 120 interacts with the MAC layer 104 via a MAC layercontext manager (MLCM) SAP 124, and the context manager 120 interactswith PHY layer 102 via a PHY layer context manager (PLCM) SAP 126.

Referring to FIG. 6, in accordance with another embodiment, a peerdevice 102 includes the context manager 120 that is implemented as apart of the MAC layer 104. Thus, the context manager (CM) 120 interactswith the PHY layer 102 via the PLCM SAP 126, and the CM 120 in FIG. 6interacts with the higher layers 106 via the HLCM SAP 122. In accordancewith the example, interactions between the context manager 120 and otherfunctions of the MAC layer 104 are within the MAC layer, and thus do notrequire primitives. As used herein, unless otherwise specified, it willbe understood that the higher layers 106 may include an applicationlayer. Thus, in accordance with the illustrated embodiments of FIG. 5and FIG. 6, an application can interface to the context manager 120 toretrieve context and manipulate context information stored at thecontext manager 120.

Table 5 below lists example functions and interactions between thecontext manager 120 and other protocol layers (e.g., PHY layer 102, MAClayer 104, and higher layers 106) in accordance with an exampleembodiment. In another aspect, the context manager 120 may maintain acontext database to support various context operations (e.g., contextupdate, context retrieve, context subscription, etc.) initiated by thehigh layers 106, MAC layer 104, and/or PHY layer 102. Each row in Table5 represents a specific interaction between a Requester (e.g., a PRL orCM) and a Receiver (e.g., CM or PRL) via an SAP (e.g., HLCM SAP 122,MLCM SAP 124, and/or PLCM SAP 126). For example, the first row in Table5 means that a protocol layer (PRL) can be a requester and can createnew context information at the context manager 120 (the receiver) viaany of the above-described SAPs (e.g., HLCM SAP 122, MLCM SAP 124, andPLCM SAP 126).

TABLE 5 Example Context Management Interactions between Context Manager(CM) and Protocol Layers (PRL) HLCM MLCM PLCM Interactions RequesterReceiver SAP SAP SAP Create new context information PRL CM ✓ ✓ ✓Retrieve existing context PRL CM ✓ ✓ information Update existing contextinformation PRL CM ✓ ✓ ✓ Delete existing context information PRL CM ✓Enable or disable context CM PRL ✓ monitoring Search existing contextinformation PRL CM ✓ ✓ Search provided context CM PRL ✓ ✓ ✓ informationSubscription request for specific PRL CM ✓ ✓ context information Notifythe change in context PRL CM ✓ subscribed Subscription request forspecific CM PRL ✓ context information Notify the change in context CMPRL ✓ ✓ subscribed Enable or disable context CM PRL ✓ measurement

In an example embodiment, the context manager 120 can be integrated witha Pad's operating system (e.g., Android, iOS, Windows 7, etc.), and theHLCM SAP 122, MLCM SAP 124, and the PLCM SAP 126 may each be implementedas an application programming interface (API) provided by a chip-setprovider for the PD. For example, for a smart tablet that has an IEEE802.15.8 (or IEEE 802.11) chipset runs Windows 7, the IEEE 802.15.8 (orIEEE 802.11) chipset APIs may include the PLCM SAP 126 for the PHY layer102 and the CM 120 may be integrated with the OS.

New primitives are now described for exchanging context information overthe PLCM SAP 126, the MLCM SAP 124, and the HLCM SAP 122 in accordancewith various embodiments. Further, example methods for leveraging thoseprimitives are also described below.

Referring now to FIGS. 7A, 7B, and 7C, various primitives are used in apeer device 201 that includes the CM 120 and the PHY layer 102.Specifically, the following primitives, presented by way of example andwithout limitation, are defined for the PLCM SAP 126 between the PHYlayer 102 and context manager 120 as depicted in FIGS. 7A, 7B, and 7C.Referring to FIG. 7A, at 702, a PLCM-REPORT.Request primitive is set tothe CM 120 from the PHY layer 102. Using this primitive, the PHY layer102 requests to add and/or update context information in the contextmanager 120. At 704, in response to the request, the CM 120 may createnew context information or update existing context information. At 706,using a PLCM-REPORT.Confirm primitive, the CM 120 sends a confirmationto the PHY layer 102.

Referring now to FIG. 7B, at 708, using a PLCM-MEASURE.Requestprimitive, the context manager 120 requests that context measurement isenabled or disabled at the PHY layer 102. At 710, if the requestincludes a request to enable designated context measurement, the PHYlayer 102 measures the designated context information. At 712, using aPLCM-MEASURE.Confirm primitive, the PHY layer 102 sends a confirmationto the context manager 120. Referring now to FIG. 7C, at 718, using aPLCM-DISCOVER.Request primitive, the context manager 120 requests tosearch context types that the PHY layer 102 provides. At 720, using aPLCM-DISCOVER.Confirm primitive, a confirmation is sent from the PHYlayer 102 to the context manager 120.

Referring again to FIG. 7A, the PLCM-REPORT.Request primitive (at 702)may contain a set of context elements to be created or updated. In anexample, each context element consists of a contextName parameter and acontextValue parameter. In addition, a context element can be containedin a standard Information Element (IE) that passes through the PLCM SAP126. The contextName parameter may identify, for instance by includingan identifier, information that should be created or updated. ThecontextValue parameter may indicate a value of the context informationthat should be created or updated. In an example embodiment, thecontextValue parameter may be excluded from the PLCM-REPORT.Requestprimitive to indicate that the PHY layer 102 should only report the nameor type of context information it provides. The PLCM.REPORT.Confirmprimitive may contain results, for instance that indicate a success orfailure, associated with each context element contained in thePLCM-REPORT.Request primitive. For example, the PLCM.REPORT.Confirmprimitive may contain a result primitive that indicates whether arequest for a context element succeeded or failed.

Referring again to FIG. 7B, the PLCM-MEASURE.Request primitive maycontain one or more context measurement elements. Each contextmeasurement element may contain the following example parameters,presented by way of example and without limitation: a flag, acontextName, and a measurePeriod. In an example, the flag parameterenables (e.g., if flag=TRUE) or disables (e.g., if flag=FALSE) themeasurement of the context information associated with the contextNameparameter. Thus, the contextName parameter (e.g., identifier) indicatesthe context information associated with the measurement. In an example,the measurePeriod parameter represents the frequency of periodicalmeasurement of the context information associated with the contextName.By way of example, if measurePeriod is zero, the associated measurementmay be only a one-time measurement. In some cases, this parameter is notrequired if flag=FALSE. In accordance with the illustrated embodiment,the PLCM.MEASURE.Confirm primitive contains a set of context elements asthe measurement results for each context measurement element ascontained in PLCM-MEASURE.Request primitive. As shown in FIG. 7B, onePLCM-MEASURE.Request primitive at 708 may generate multiplePLCM-MEASURE.Confirm primitives (e.g., 712 and 716). For example, thePLCM-MEASURE.Request primitive may trigger periodic measurements (e.g.,710 and 714) at the PHY layer 102 and each of the measurements maygenerate a PLCM-MEASURE.Confirm primitive. In another example, onePLCM-MEASURE.Confirm may contain one, for instance only one, contextelement. Each context element may contain the following parameters,presented by way of example and without limitation: contextName,contextValue, and result. The contextName parameter name (e.g., anidentifier) may identify context information that should be created orupdated. The contextValue parameter may indicate the value of thecontext information that should be created or updated. The resultparameter may indicate whether the measurement was successful or failed.If the result is failure, contextName and contextValue is not includedin PLCM-MEASURE. Confirm primitive in accordance with one example, andthe CM 120 may issue another PLCM-MEASURE.Request.

Referring again to FIG. 7C, the PLCM-DISCOVER.Request primitive maycontain a set of search criteria, which may be represented by asearchCriteria context element. The search criteria element may be usedfor discovering corresponding context names or context types. The searchcriteria may include various parameters, such as, for example,contextName, keywords related to contextName, etc. At 720, thePLCM.DISCOVER.Confirm primitive may contain a set of context elementsthat match the searchCriteria contained in the PLCM-DISCOVER.Requestprimitive. Each element may contain parameters, for instance thecontextName and contextValue parameters. In an example case, when thisprimitive contains no context elements, it means that no contextinformation matched the searchCriteria.

It will be understood that the contextName parameter described hereinmay be exchanged over the PLCM SAP 126, HLCM SAP 122, and the MLCM SAP124, and may be a full name or a partial name. For example, a partialname may be a key word related to one or more full names. In anotherexample, if the full name is a structured name including multiple parts,the partial name may be one of those parts. In some cases, if thecontextName is a partial name, the CM 120 analyzes the partial name andfinds corresponding full name(s) that match(es) the partial name.

Referring now to FIGS. 8A-B, various primitives are used by a peerdevice 201 a that includes the CM 120, the higher layers 106, and theMAC layer 104. In the illustrated examples, the peer device 201 a sendsa request, and thus the peer device 201 a may also be referred to as arequestor 201 a or an originator 201 a. FIGS. 8A-B shows example callflows using example primitives for reporting context information fromthe higher layers 106 to the context manager 120, where the contextmanager 120 is not a part of the MAC layer 104. FIG. 8A illustrates anexample local context information reporting scenario and FIG. 8Billustrates an example remote information reporting scenario.

Referring first to FIG. 8A, in accordance with the illustrated example,at 802, the higher layer 106 of the PD 201 a sends a HLCM-REPORT.Requestprimitive to the context manager 120 of the PD 201 a. The primitivecontains the contextName and contextValue parameters, as describedabove. At 804, the CM 120 of the PD 201 a sends a HLCM-REPORT.Confirmprimitive to the high layer 106. This primitive contains the resultassociated with the request (e.g., successful or failed).

Referring to FIG. 8B, in accordance with the illustrated example, theHLCM-REPORT.Request primitive that is sent at 802 contains a contextNameparameter, a contextValue parameter, and identifiers of one or remotepeer devices. In accordance with the illustrated example, one of theidentifiers corresponds to a peer device 201 b, which can also bereferred to as a recipient PD 201 b. At 806, the context manager 120 ofthe originator PD 201 a sends an MLCM-REPORT.Request primitive to thecontext manager 120 of the PD 201 a. This primitive containscontextName, contextValue, and identifiers of the one or more remotepeer devices. At 808, the MAC layer 104 of the PD 201 a sends a ContextReport Request message over the air to the MAC layer 104 of therecipient PD 201 b. This message may contain various parametersincluding the contextName, contextValue, etc. At 810, the MAC layer 104of the recipient PD 201 b sends a MLCM-REPORT.Indication primitive tothe context manager 120 of the PD 201 b. At 812, in accordance with theillustrated example, the context manager of the PD 201 b sends aHLCM-REPORT.Indication primitive to the higher layer 106 of the PD 201b. At 814, the higher layer 106 of the recipient PD 201 b sends aHLCM-REPORT.Response primitive to the context manager 120 of the PD 201b. At 816, the CM 120 of the PD 201 b sends a MLCM-REPORT.Responseprimitive to the MAC layer 104 of the PD 201 b. At 818, in accordancewith the illustrated example, the MAC layer 104 of the PD 201 b sends aContext Report Response message over the air to the MAC layer 104 of thePD 201 a. This message may contain parameters such as, for example, thecontextName and the context report result (e.g., successful or failure).At 820, the originator MAC layer 104 sends a MLCM-REPORT.Confirmprimitive to the originator context manager 120 to indicate the contextreport result (e.g., successful or failure). At 804, CM 120 of the PD201 a sends the HLCM-REPORT.Confirm primitive described above to thehigher layer 106 of the PD 201 a.

FIG. 9 shows an example in which the context manager 120 of theoriginator PD 201 a is a part of the MAC layer 104, and the contextmanager 120 of the recipient PD 201 b is a part of the MAC layer 104, inaccordance with an example embodiment. The steps are described withreference to FIGS. 8A and 8B, and thus reference numbers in FIG. 9 arerepeated from FIGS. 8 8A and 8B. It will be understood that in anexample embodiment in which only local context information (e.g.,information associated with the PD 201 a) is reported, steps 808, 812,814, and 818 are not performed. Referring to 802, theHLCM-REPORT.Request primitive may contain a set of context elements tobe created or updated. Each context element may consist of parameters,for example and without limitation, a contextName parameter, acontextValue parameter, and a peerID parameter. The contextNameparameter may identify the context information that is requested to becreated or updated. The contextValue parameter may indicate the contextinformation value that requested to be created or updated. In anexample, if this parameter is not included, it means that the high layer106 only reports the name or type of context information it provides ThepeerID parameter may identify one or more remote peer devices (e.g.,recipient 201 b) that should report their context in accordance with therequest. This parameter may contain multiple identifiers, for example,if the high layer 106 of the originator 201 b requests that contextinformation be updated at multiple remote peer devices. Referring to812, the HLCM-REPORT.Indication primitive may contain one or more, forinstance a set, of context elements that are received from theoriginator 201 a. Each context element may consist of one or moreparameters, such as, for example, the contextName parameter, whichidentifies the context information associated with the request; thecontextValue parameter, which is indicative of the value of therequested context information; and the peerID, which identifies theoriginator 201 a for reporting of the requested remote contextinformation.

With continuing reference to FIGS. 8A-B and 9, at 814, theHLCM-REPORT.Response primitive may contain a simple acknowledgement ofthe HLCM-REPORT.Indication primitive that is received. Referring to 804,the HLCM.REPORT.Confirm primitive may contain one or more results, forinstance a set of result elements, associated with each context elementthat was as indicated in the HLCM-REPORT.Request primitive. Each resultelement may contain one or more parameters, for instance and withoutlimitation: the contextName parameter, the result parameter, and thepeerID parameter, which may identify the remote peer device (e.g., peer201 b) that sends back the remote context report response at 818.

Referring now to FIGS. 10A and 10B, the higher layers 106, for instancethe application layer, may retrieve context information from a localcontext manager 120 or a remote context manager 120. FIG. 10A shows anexample call flow in which the context manager 120 is a part of the MAClayer 104, and FIG. 10B shows an example call flow in which the contextmanager 120 is not part of MAC layer 104. Illustrated steps 1502, 1508,1510, and 1514 are described further herein with reference to FIG. 15.

Referring to FIGS. 10A and 10B, at 1002, the high layer 106 of theoriginator PD 201 a sends an HLCM-RETRIEVE.Request primitive to thecontext manager 120 of the PD 201 a. In an example, this primitivecontains contextName and one or more identifiers associated with one ormore remote peer devices, for instance recipient PD 201 b. In an exampleembodiment, the HLCM-RETRIEVE.Request primitive contains a set ofcontext elements that need to be updated. Each context element mayconsist of one or more, for instance two, parameters such as, forexample and without limitation, the contexName parameter and the peerIDparameter. The contextName parameter identifies the context informationthat is being retrieved by the higher layer 106 of the PD 201 a. ThepeerID parameter identifies remote peer devices (e.g., recipient PD 201b) from which context information is being retrieved. This parameter maycontain multiple identifiers, for example, if the high layer 106 wantsto retrieve context information from multiple remote peer devices.

At 1004, in accordance with the illustrated example, the MAC layer 104at the PD 201 a sends a Context Retrieve Request message over the air tothe MAC layer 104 of the recipient 201 b. This message may contain, forexample, the contextName parameter. At 1006, the context manager 120 ofthe recipient 201 b sends an HLCM-RETRIEVE.Indication primitive to thehigher layer 106 of the PD 201 b. The HLCM-RETRIEVE.Indication primitivemay contain a set of context elements received from the originator PD201 a. Each context element may consist of one or more, for instancetwo, parameters, such as, for example the contextName parameter and thepeerID parameter. Here, the peerID parameter may identify the originatorPD 201 a, and the contexName parameters identifies the contextinformation that is being retrieved. At 1008, the high layer 106 of therecipient PD 201 b sends an HLCM-RETRIEVE.Response primitive to thecontext manager 120 of the recipient PD 201 b. In an example embodiment,the HLCM-RETRIEVE.Response primitive contains an acknowledgement of theHLCM-RETRIEVE.Indication primitive, and may contain a contextValuecorresponding to the contextName. At 1010, in accordance with theillustrated example, the MAC layer 104 of the recipient PD 201 b sends aContext Retrieve Response message over the air to the MAC layer of thePD 201 a. This message may contain various information, such as, forexample, the contextValue and contextName parameters. At 1012, thecontext manager 120 of the PD 201 a sends a HLCM-RETRIEVE.Confirmprimitive to the high layer 106 of the PD 201 a. TheHLCM-RETRIEVE.Confirm primitive may contain a set of result elementsassociated with each received context element as indicated in theHLCM-RETRIEVE.Request primitive. Each result element may contain one ormore, for instance three, parameters such as, for example, thecontextName, contextValue, and peerID. For example, the peerID parametermay identify the remote peer device 201 a that sends back the responseto the context retrieval request. The contextValue parameter identifiesthe value of the context information. In one embodiment, contextinformation is retrieved locally from the PD 201 a, and thus steps 1004,1006, 1008, and 1010 are not performed.

Referring now to FIGS. 11A and 11B, the higher layer 106, for instancean application layer, may delete context information in accordance withan example embodiment. Context information can be deleted from a localcontext manager or a remote context manager. FIG. 11A shows an examplecall flow in which the context manager 120 is a part of the MAC layer104, and FIG. 11B shows an example call flow in which the contextmanager 120 is not a part of MAC layer 104. Steps 1602 a, 1608, 1610,and 1614 are further described below with reference to FIG. 16.

Referring to FIGS. 11A and 11B, in accordance with the illustratedembodiment, at 1102, high layer 106 of the PD 201 a sends anHLCM-DELETE.Request primitive to the context manager 120 of the PD 201a. This primitive contains the contextName parameter and identifiers ofremote peer devices associated with context information that the highlayer 106 of the PD 201 a wants to delete. The HLCM-DELETE.Requestprimitive may contain a set of context elements to be deleted. Eachcontext element consists of one or more, for instance two, parameters,such as for example, the contextName and the peerID. The contextNameparameter may identify context information for deletion. The peerIDparameter may identify remote peer devices (e.g., PD 201 b) that shoulddelete context information. This parameter may contain multipleidentifiers, for example, if the high layer 106 of the PD 201 a requeststhat context information is deleted from multiple devices. At 1104, MAClayer 104 of the PD 201 a sends a Context Delete Request message overthe air to the MAC layer 104 of the recipient PD 201 b. In response, at1106, the context manager 120 of the PD 201 b sends aHLCM-DELETE.Indication primitive to the high layer 106 of the PD 201 b.The HLCM-DELETE.Indication primitive may a set of context elementsreceived from the originator PD 201 a. Each context element may consistof, for example, the contextName parameter and the peerID parameter.Here, the peerID parameter may identify the originator peerID 201 a. At1108, the high layer 106 of the PD 201 b sends an HLCM-DELETE.Responseprimitive to the context manager 120 of the PD 201 b. TheHLCM-DELETE.Response primitive may contain an acknowledgement of theHLCM-DELETE.Indication primitive. At 1110, the MAC layer 104 of therecipient 201 b sends a Context Delete Response message over the air tothe MAC layer 104 of the PD 201 a. This message may contain thecontextName and a context deletion result (e.g., success or fail). At1112, the context manager 120 of the PD 201 a sends anHLCM-DELETE.Confirm primitive to high layer 106 of the PD 201 a toindicate the context deletion result (e.g., success or fail). In anexample, the HLCM-DELETE.Confirm primitive contains a set of resultelements for each received context element as indicated in theHLCM-DELETE.Request primitive. Each result element may contain one ormore parameters, such as, for example, the contextName primitive, theresult primitive, and the peerID primitive. In accordance with theillustrated example, the result primitive may indicate whether thecontext information was successfully deleted. The peerID primitiveidentifies the remote peer device (e.g., peer 201 b) that sends back thecontext delete response. In one embodiment, context information isdeleted locally from the originator PD 201 a, and thus steps 1104, 1106,1108, and 1110 are not performed.

Referring now to FIGS. 12A and 12B, the higher layers 106, for instancean application layer, may subscribe to context information in accordancewith an example embodiment. The high layer 106 can subscribe to contextinformation from a local context manager or a remote context manager.FIG. 12A shows an example call flow for context subscription in whichthe context manager 120 is a part of the MAC layer 104. FIG. 12B showsan example call flow for context subscription in which the contextmanager 120 is not a part of MAC layer 104. Steps 1702 a, 1708, 1710,and 1714 are described further below with reference to FIG. 17.

At 1202, as shown, the high layer 106 of the originator PD 201 a sendsan HLCM-SUBSCRIBE.Request primitive to the context manager 120 of the PD201 a. This primitive may contain a set of context elements to which thehigh layer 106 wants to subscribe. Each context element may includeparameters, such as, for example, a contextName parameter, asubscriptionCriteria parameter, a timeDuration parameter, and a peerIDparameter. The contextName parameter may identify the contextinformation associated with the subscription. The subscriptionCriteriaparameter may indicate a condition or criteria. If the condition orcriteria is met, a notification may be provided to the subscribingdevice. A condition may be a predetermined frequency or a time intervalwithout receiving a notification. The timeDuration parameter mayindicate the lifetime of the requested subscription. The peerIDparameter may identifier one or more peer devices (e.g., recipient PD201 b) to which the PD 201 a wants to subscribe. At 1204, in accordancewith the illustrated example, the MAC layer 104 of the originator 201 asends a Context Subscribe Request message over the air to the MAC layer201 b of the recipient 201 b. This message may contain variousinformation, such as the information included in the request primitiveat 1202. At 1206, context manager 120 of the recipient PD 201 b sends anHLCM-SUBSCRIBE.Indication primitive to the high layer 106 of therecipient 201 b. The HLCM-SUBSCRIBE.Indication primitive may contain aset of context elements received from the originator PD 201 a. Eachcontext may include, for example, the contextName parameter, whichindicates context information associated with the subscription request,and the peerID parameter, which identifies the originator PD 201 a ofthe subscription request. At 1208, the high layer 106 of the recipientPD 201 b sends a HLCM-SUBSCRIBE.Response primitive to the contextmanager 120 of the recipient PD 201 b. The HLCM-SUBSCRIBE.Responseprimitive may contain an acknowledgement of theHLCM-SUBSCRIBE.Indication primitive. At 1210, the MAC layer 104 of therecipient PD 201 b sends a Context Subscribe Response message over theair to the MAC layer 104 of the originator 201 a. This message maycontain various information, such as, for example, the contextName andthe context subscription result (e.g., success or fail). At 1212, inaccordance with the illustrated embodiment, the context manager 120 ofthe originator PD 201 sends a HLCM-SUBSCRIBE.Confirm primitive to thehigh layer 106 of the originator PD 201 a to indicate the contextsubscription result (e.g., success or fail). The HLCM-SUBSCRIBE.Confirmprimitive may contain a set of result elements for each context elementindicated in HLCM-SUBSCRIBE.Request primitive. Each result element maycontain one or more parameters, for example the contextName parameter,the timeDuration parameter, and the peerID parameter. Here, thecontextName parameter identifies the context information associated withthe subscription. The timeDuration parameter may indicate a lifetime ofthe subscription. In one example, the lifetime may be assigned by the PD201 b. In some cases, a lifetime value of ‘zero’ indicates that thesubscription request was rejected. The peerID parameter identifies theremote device associated with the subscription. In accordance with theillustrated example, the peerID parameter identifies the PD 201 b thatsent the response to the subscription request.

Referring now to FIGS. 13A and 13B, the context manager 120 provides anotification to the recipient PD 201 b. FIG. 13A shows an example callflow in the context manager 120 is a part of the MAC layer 104, and FIG.13B shows an example call flow in which the context manager 120 is not apart of the MAC layer 104. Illustrated steps 1802 a, 1808, 1810 and 1814are further described herein with reference to FIG. 18.

In accordance with one embodiment, steps 1302 and 1304 are used in localcontext notification and steps 1306, 1308, and 1310 are used in remotecontext notification. At 1302, the context manager 120 of the originatorPD 201 a (originator context manager 120) sends an HLCM-NOTIFY.Requestprimitive to the high layer 106 of the originator PD 201 a. TheHLCM-NOTIFY.Request primitive may contain a set of context elements,each of which may include one or more parameters, such as, for example,the contextName, contextValue, and peerID. Here, the contextNameidentifies the context information associated with the notification. ThecontextValue indicates the value of context information associated withthe notification. The peerID parameter may identify devices (e.g., PD201 b) associated with the notification. In an example, this parameteris not required for local context information notification. At 1304, thehigh layer 106 of the originator PD 201 a (originator high layer 106)sends a HLCM-NOTIFY.Confirm primitive to the context manager 120 of theoriginator PD 201 a. At 1306, in accordance with the remote notificationexample, the MAC layer 104 of the PD 201 a (originator MAC layer 104)sends a Context Notify Request message over the air to the MAC layer 104of the PD 201 b (recipient MAC layer 104). This message may containvarious information such as, for example, contextName, contextValue,etc. At 1308, the context manager 120 of the PD 201 b sends aHLCM-NOTIFY.Indication primitive to the recipient high layer 106. At1310, the recipient high layer 106 sends a HLCM-NOTIFY.Responseprimitive to the recipient context manager 120. At 1312, the recipientMAC layer 104 sends a Context Notify Response message over the air tothe originator MAC layer 104 as an acknowledgement. As described above,the HLCM-NOTIFY.Confirm primitive may contain the contextName parameterand the peerID parameter. The contextName parameter may identify thecontext information associated with the notification. Here, the peerIDparameter may identify the recipient device associated with the remotenotification.

Referring now to FIG. 14, examples of reporting context information areshown. At 1406, in accordance with a local reporting example, the MAClayer 106 of the originator PD 201 a sends an MLCM-REPORT.Requestprimitive to the context manager 120 of the PD 201 a. At 1407, thecontext manager 120 of the PD 201 a sends a MLCM-RETRIEVE.Confirmprimitive to the MAC layer 104 of the PD 201 a. TheMLCM-RETRIEVE.Confirm primitive may contain a set of result elementsassociated with each context element indicated in theMLCM-RETRIEVE.Request primitive. Each result element may contain one ormore parameters such as, for example, the contextName and contextValueparameters. For example, the contextValue parameter identifies the valueof the context information.

Still referring to FIG. 14, a remote reporting example of reportingcontext information associated with a remote device is depicted. At 1406a, the originator context manager 120 sends the MLCM-REPORT.Requestprimitive to the originator MAC layer 104. The MLCM-REPORT.Requestprimitive may contain a set of context elements associated with anupdate or creation request. Each context element may consist of thecontextName parameter, the peerID parameter, and the contextValueparameter, as described above with reference to FIGS. 8A and 8B. At1408, the originator MAC layer 104 sends the Context Update Requestmessage over the air to the recipient MAC layer 104. This message maycontain various information such as, for example, values, names, andpeer identifiers associated with the request for context information. At1410, the recipient MAC layer 104 sends the MLCM-REPORT.Indicationprimitive to the recipient context manager 120. At 1416, the recipientcontext manager 120 sends the MLCM-REPORT.Response primitive to therecipient MAC layer 104. At 1418, the recipient MAC layer 104 sends aContext Update Response message over the air to the originator MAC layer104. This message may contain various information such as, for example,a result associated with the report request. At 1420, the originator MAClayer 104 sends the MLCM-REPORT.Confirm primitive to the originatorcontext manager 120. The MLCM.REPORT.Confirm primitive may contain a setof result elements associated with each context element in the request.As further described with reference to FIGS. 8A and 8B, each resultelement may various parameters, such as the contextName parameter, theresult parameter, and the peerID parameter.

Referring now to FIG. 15, examples of retrieving context information areshown. At 1502, in accordance with a local retrieving example, the MAClayer 106 of the originator PD 201 a sends an MLCM-RETRIEVE.Requestprimitive to the context manager 120 of the PD 201 a. At 1503, thecontext manager 120 of the PD 201 a sends a MLCM-RETRIEVE.Confirmprimitive to the MAC layer 104 of the PD 201 a. TheMLCM-RETRIEVE.Confirm primitive may contain a set of result elementsassociated with each context element indicated in theMLCM-RETRIEVE.Request primitive. Each result element may contain one ormore parameters such as, for example, the contextName and contextValueparameters. For example, the contextValue parameter identifies the valueof the context information.

At 1502 a, in accordance with a remote retrieval example, the contextmanager 120 of the originator PD 201 a sends an MLCM-RETRIEVE.Requestprimitive to the MAC layer 104 of the PD 201 a. In an example, thisprimitive contains contextName and one or more identifiers associatedwith one or more remote peer devices, for instance recipient PD 201 b.In an example embodiment, the MLCM-RETRIEVE.Request primitive contains aset of context elements that need to be updated. Each context elementmay consist of one or more, for instance two, parameters such as, forexample and without limitation, the contexName parameter and the peerIDparameter. The contextName parameter identifies the context informationthat is being retrieved by the MAC layer 104 of the PD 201 a. The peerIDparameter may identify remote peer devices (e.g., recipient PD 201 b ina remote retrieval scenario) from which context information is beingretrieved. This parameter may contain multiple identifiers, for example,if the MAC layer 104 wants to retrieve context information from multipleremote peer devices.

At 1506, in accordance with the illustrated example, the MAC layer 104at the PD 201 a sends a Context Retrieve Request message over the air tothe MAC layer 104 of the recipient 201 b. This message may contain, forexample, the contextName parameter. At 1508, the context manager 120 ofthe recipient 201 b sends an MLCM-RETRIEVE.Indication primitive to theCM 120 of the PD 201 b. The MLCM-RETRIEVE.Indication primitive maycontain a set of context elements received from the originator PD 201 a.Each context element may consist of one or more, for instance two,parameters, such as, for example the contextName parameter and thepeerID parameter. Here, the peerID parameter may identify the originatorPD 201 a, and the contexName parameters identifies the contextinformation that is being retrieved. At 1510, the CM 120 of therecipient PD 201 b sends an MLCM-RETRIEVE.Response primitive to the MAClayer 104 of the recipient PD 201 b. In an example embodiment, theMLCM-RETRIEVE.Response primitive contains an acknowledgement of theMLCM-RETRIEVE.Indication primitive, and may contain a contextValueparameter corresponding to the contextName. At 1512, in accordance withthe illustrated example, the MAC layer 104 of the recipient PD 201 bsends a Context Retrieve Response message over the air to the MAC layer104 of the PD 201 a. This message may contain various information, suchas, for example, the contextValue and contextName parameters. At 1514,the MAC layer 104 of the PD 201 a sends a MLCM-RETRIEVE.Confirmprimitive to the context manager 120 of the PD 201 a. TheMLCM-RETRIEVE.Confirm primitive may contain a set of result elementsassociated with each context element indicated in theMLCM-RETRIEVE.Request primitive. Each result element may contain one ormore, for instance three, parameters such as, for example, thecontextName, contextValue, and peerID. For example, the peerID parametermay identify the remote peer device 201 a that sends back the responseto the context retrieval request. The contextValue parameter identifiesthe value of the context information.

Referring now to FIG. 16, another example of deleting contextinformation is shown. At 1602, in accordance with the illustrated localdelete example, the MAC layer 106 of the originator PD 201 a sends anMLCM-DELETE.Request primitive to the context manager 120 of the PD 201a. At 1604, the context manager 120 of the PD 201 a sends aMLCM-DELETE.Confirm primitive to the MAC layer 104 of the PD 201 a. TheMLCM-DELETE.Confirm primitive may contain a set of result elementsassociated with each context element indicated in theMLCM-DELETE.Request primitive. Each result element may contain one ormore parameters such as, for example, the contextName and contextValueparameters. For example, the contextValue parameter identifies the valueof the context information.

At 1602 a, in accordance with the illustrated remote delete example, thecontext manager 120 of the PD 201 a sends an MLCM-DELETE.Requestprimitive to the MAC layer 104 of the PD 201 a. This primitive containsthe contextName parameter and identifiers of remote peer devicesassociated with context information that the MAC layer 104 of the PD 201a wants to delete. The MLCM-DELETE.Request primitive may contain a setof context elements associated with the delete request. Each contextelement consists of one or more, for instance two, parameters, such as,for example, the contextName and the peerID. The contextName parametermay identify the context information associated with the delete request.The peerID parameter may identify remote peer devices (e.g., PD 201 b)that should delete context information. This parameter may containmultiple identifiers, for example, if the MAC layer 104 of the PD 201 arequests that context information is deleted from multiple devices. At1606, the MAC layer 104 of the PD 201 a sends a Context Delete Requestmessage over the air to the MAC layer 104 of the recipient PD 201 b. Inresponse, at 1608, the MAC layer 104 of the PD 201 b sends aMLCM-DELETE.Indication primitive to the context manager 120 of the PD201 b. The MLCM-DELETE.Indication primitive may contain a set of contextelements received from the originator PD 201 a. Each context element mayconsist of, for example, the contextName parameter and the peerIDparameter. Here, the peerID parameter may identify the originator peerID201 a. At 1610, the MAC layer 104 of the PD 201 b sends anMLCM-DELETE.Response primitive to the context manager 120 of the PD 201b. The MLCM-DELETE.Response primitive may contain an acknowledgement ofthe MLCM-DELETE.Indication primitive. At 1612, the MAC layer 104 of therecipient 201 b sends a Context Delete Response message over the air tothe MAC layer 104 of the PD 201 a. This message may contain thecontextName and a context deletion result (e.g., success or fail)associated with the remote delete request. At 1614, the MAC layer 104 ofthe PD 201 a sends an MLCM-DELETE.Confirm primitive to context manager120 of the PD 201 a to indicate the context deletion result (e.g.,success or fail). In an example, the MLCM-DELETE.Confirm primitivecontains a set of result elements for each received context element asindicated in the MLCM-DELETE.Request primitive. Each result element maycontain one or more parameters, such as, for example, the contextNameprimitive, the result primitive, and the peerID primitive. In accordancewith the illustrated example, the result primitive may indicate whetherthe context information was successfully deleted. The peerID primitiveidentifies the remote peer device (e.g., peer 201 b) that sends back thecontext delete response.

Referring now to FIG. 17, examples of subscribing to context informationare shown. At 1702 and 1704, an example local subscription isimplemented. At 1202, as shown, the MAC layer 104 of the originator PD201 a sends an MLCM-SUBSCRIBE.Request primitive to the context manager120 of the PD 201 a. This primitive may contain a set of contextelements to which the MAC layer 104 wants to subscribe. Each contextelement may include parameters, such as, for example, a contextNameparameter, a subscriptionCriteria parameter, a timeDuration parameter,and a peerID parameter. At 1704, the context manager 120 of theoriginator PD 201 a sends a MLCM-SUBSCRIBE.Confirm primitive to the MAClayer 104 of the originator PD 201 a to indicate the contextsubscription result (e.g., success or fail).

At 1702 a, in accordance with the illustrated remote subscriptionexample, the originator CM 120 may send the MLCM-SUBSCRIBE.Requestprimitive to the MAC layer 104 of the PD 201 a. The contextNameparameter may identify the context information associated with thesubscription. The subscriptionCriteria parameter may indicate acondition or criteria. If the condition or criteria is met, anotification may be provided to the subscribing device. A condition maybe a predetermined frequency or a time interval without receiving anotification. Thus, for example, when the time interval elapses, anotification is sent to the originator PD 201 a. The timeDurationparameter may indicate the lifetime of the requested subscription. ThepeerID parameter may identify one or more peer devices (e.g., recipientPD 201 b) to which the PD 201 a wants to subscribe. At 1706, inaccordance with the illustrated example, the MAC layer 104 of theoriginator 201 a sends a Context Subscribe Request message over the airto the MAC layer 201 b of the recipient 201 b. This message may containvarious information, such as the information included in the requestprimitive at 1702 a. At 1708, the MAC layer 104 of the recipient PD 201b sends an MLCM-SUBSCRIBE.Indication primitive to the context manager120 of the recipient 201 b. The MLCM-SUBSCRIBE.Indication primitive maycontain a set of context elements received from the originator PD 201 a.Each context may include, for example, the contextName parameter, whichindicates context information associated with the subscription request,and the peerID parameter, which identifies the originator PD 201 a ofthe subscription request. At 1710, the context manager 120 of therecipient PD 201 b sends a MLCM-SUBSCRIBE.Response primitive to the MAClayer 104 of the recipient PD 201 b. The MLCM-SUBSCRIBE.Responseprimitive may contain an acknowledgement of theMLCM-SUBSCRIBE.Indication primitive. At 1712, the MAC layer 104 of therecipient PD 201 b sends a Context Subscribe Response message over theair to the MAC layer 104 of the originator 201 a. This message maycontain various information, such as, for example, the contextName andthe context subscription result (e.g., success or fail). At 1714, inaccordance with the illustrated embodiment, the MAC layer 104 of theoriginator PD 201 a sends a MLCM-SUBSCRIBE.Confirm primitive to thecontext manager 120 of the originator PD 201 a to indicate the contextsubscription result (e.g., success or fail). The MLCM-SUBSCRIBE.Confirmprimitive may contain a set of result elements for each context elementindicated in MLCM-SUBSCRIBE.Request primitive. Each result element maycontain one or more parameters, for example the contextName parameter,the timeDuration parameter, and the peerID parameter. Here, thecontextName parameter identifies the context information associated withthe subscription. The timeDuration parameter may indicate a lifetime ofthe subscription. In one example, the lifetime may be assigned by the PD201 b. In some cases, a lifetime value of ‘zero’ indicates that thesubscription request was rejected. The peerID parameter identifies theremote device associated with the subscription. In accordance with theillustrated example, the peerID parameter identifies the PD 201 b thatsent the response to the subscription request.

Referring now to FIG. 18, examples for notifying a device of contextinformation are shown. In accordance with one embodiment, steps 1802 and1804 are used in local context notification and steps 1802 a, 1806,1808, 1810, 1812, and 1814 are used in remote context notification. At1802, the originator MAC layer 104 sends an MLCM-NOTIFY.Requestprimitive to the context manager 120 of the originator PD 201 a. TheHLCM-NOTIFY.Request primitive may contain a set of context elements,each of which may include one or more parameters, such as, for example,the contextName and contextValue. Here, the contextName identifies thecontext information associated with the notification. The contextValueindicates the value of context information associated with thenotification. At 1804, the context manager 120 of the originator PD 201a (originator context manager 120) sends a MLCM-NOTIFY.Confirm primitiveto the MAC layer 104 of the originator PD 201 a.

At 1802 a, the context manager 120 of the originator PD 201 a(originator context manager 120) sends an MLCM-NOTIFY.Request primitiveto the MAC layer 104 of the originator PD 201 a. The MLCM-NOTIFY.Requestprimitive may contain a set of context elements, each of which mayinclude one or more parameters, such as, for example, the contextName,contextValue, and peerID. Here, the contextName identifies the contextinformation associated with the notification. The contextValue indicatesthe value of context information associated with the notification. ThepeerID parameter may identify devices (e.g., PD 201 b) associated withthe notification. In an example, this parameter is not required forlocal context information notification. At 1806, in accordance with theremote notification example, the MAC layer 104 of the PD 201 a(originator MAC layer 104) sends a Context Notify Request message overthe air to the MAC layer 104 of the PD 201 b (recipient MAC layer 104).This message may contain various information such as, for example,contextName, contextValue, etc. At 1808, the MAC layer 104 of the PD 201b sends a MLCM-NOTIFY.Indication primitive to the context manager 120 ofthe PD 201 b. At 1810, the context manager 120 sends aMLCM-NOTIFY.Response primitive to the recipient MAC layer 104. At 1812,the recipient MAC layer 104 sends a Context Notify Response message overthe air to the originator MAC layer 104 as an acknowledgement. At 1814,MAC layer 104 of the originator PD 201 a (originator context manager120) sends a MLCM-NOTIFY.Confirm primitive to the context manager 120 ofthe originator PD 201 a. As described above, the MLCM-NOTIFY.Confirmprimitive may contain the contextName parameter and the peerIDparameter. The contextName parameter may identify the contextinformation associated with the notification. Here, the peerID parametermay identify the recipient device associated with the remotenotification.

Thus, as described above with general reference to FIGS. 4-18, a peerdevice, for instance a first peer device, can comprise a processor, amemory, and communication circuitry. The first peer device may beconnected to a communications network via its communication circuitry,and the first peer device may further comprise computer-executableinstructions stored in the memory of the first peer device which, whenexecuted by the processor of the first peer device, cause the first peerdevice to, at a higher layer above a medium access control (MAC) layerin a protocol stack of the first peer device, initiate a requestassociated with context information. As described above, the request mayinclude a subscription request, a report request, a notificationrequest, or a delete request. The first peer device may send, via acontext manger, a first primitive associated with the request to the MAClayer. In response to the first primitive, the first peer device mayreceive another primitive, for instance a second primitive, at thehigher layer. The second primitive may indicate a result associated withthe request. Furthermore, based on the request, the first peer devicemay send a context request to a MAC layer of a second peer device thatis in peer-to-peer communications with the first peer device. Forexample, the context request may cause the MAC layer of the second peerdevice to send a third primitive to a higher layer of the second peerdevice, such that the higher layer of the second peer device producesthe result indicated by the second primitive. Thus, as described above,the first and second primitives may be associated with at least one of asubscription request, a report request, a notification request, or adelete request.

As also described above with general reference to FIGS. 4-18, a systemmay include a recipient peer device that includes a physical (PHY)layer, a medium access control (MAC) layer above the PHY layer in aprotocol stack, and a higher layer above the MAC layer in the protocolstack. At the MAC layer of the recipient peer device, a request from anoriginator peer device may be received. The request may be associatedwith context information. As described above, the recipient peer devicemay generate a primitive, for instance a first primitive, associatedwith the request and the context information. The recipient peer devicemay send the first primitive to the higher layer above the MAC layer. Atthe higher layer, the recipient device may generate a result associatedwith the request. For example, the recipient device may generate anotherprimitive, for instance a second primitive, which is indicative of theresult. The second primitive may be sent from the higher layer to theMAC layer. At the MAC layer, the recipient device may send a response tothe originator peer device. The response may be indicative of theresult. Primitives, for instance the first and second primitives, may beassociated with at least one of a subscription request, a reportrequest, a notification request, or a delete request.

As shown in FIG. 2, in an existing service primitive model, one“Request” primitive results in one “Confirm” primitive at the samedevice (e.g., requester 201 a) and potentially a pair of “Indication”and “Response” primitives at the other device (e.g., recipient 201 b).Referring to FIGS. 19 and 20, service primitive models 1900 and 2000 areillustrated, respectively, in accordance with an example embodiment. Asshown, one “Request” primitive 1902 may result in multiple “Confirm”primitives 1904 at the same device (requester 201 a) and potentiallymultiple pairs of “Indication” and “Response” primitives at the otherdevices (one or multiple recipients). By using the illustrated models1900 and 2000, the number of “Request” primitives 1902 that a serviceuser (high layer 106 or MAC layer 104) needs to issue may be reduced ascompared to existing models.

FIG. 19 illustrates an example model 1900 that includes one requestor201 a and multiple recipients 201, for instance first, second, and thirdrecipients 201 a, 201 b, 201 c, respectively. It will be understood thatalthough three recipients 201 are illustrated, the model 1900 can beapplied to any number of recipients as desired. As shown the “Request”primitive 1902 from the high layer 106 at the requestor 201 a triggersthe requestor 201 a to send messages to multiple other devices, inparticular a first recipient 201 a, a second recipient 201 b, and athird recipient 201 c. Accordingly, there is potentially an “Indication”primitive 1906 and a “Response” 1908 primitive exchanged at each of thedevices 201 a-c. As shown, the requestor 201 a can generate multiple“Confirm” primitives, for instance a first Confirm primitive 1904 a, asecond Confirm primitive 1904 b, and a third Confirm primitive 1904 c.Alternatively, the requestor 201 a can generate an aggregated confirmprimitive 1910. By way of example, the high protocol layer 106 may issuea single association “Request” primitive to the MAC layer 104 to triggerit to associate with multiple other devices. For each successfulassociation, the MAC layer 104 may send a “Confirm” primitive back tothe high layer 106, or the MAC layer 104 may send the aggregatedassociation “Confirm” primitive 1910 back to the high layer 106 aftercompleting association with each of the designated devices. By way ofanother example, the high protocol layer 106 may trigger the MAC layer104 to trigger the device 201 a to synchronize with multiple otherdevices, for instance, which are deployed at a home or in an office.

Thus, as described with reference to FIG. 19, a device, for instance afirst peer device, may comprise a processor, a memory, and communicationcircuitry. The first peer device may be connected to a communicationsnetwork via its communication circuitry. The first peer device mayfurther comprise computer-executable instructions stored in the memoryof the first peer device which, when executed by the processor of thefirst peer device, cause the first peer device to initiate request (at ahigher layer above the MAC layer) that is associated with contextinformation. The first peer device may send, via a context manger, afirst primitive associated with the request to the MAC layer. Inresponse to the first primitive, the first peer device may receive atleast a second primitive at the higher layer. The second primitive mayindicate a result associated with the request. Furthermore, as shown,based on the request, the first peer device may send a context requestto a MAC layer of a plurality of peer devices, such that the pluralityof peer devices can each respond to the context request. Thus, the firstpeer device may receive a plurality of responses associated with therequest from the plurality of peer devices. The first peer device mayaggregate the plurality of responses into an aggregated primitive.

FIG. 20 depicts the example model 2000 that includes one requestordevice 201 a and one recipient device 201 b. Referring to FIG. 20, inaccordance with the illustrated embodiment, the “Request” primitive 1902triggers multiple “Indication” primitives 1906 a-c and “Response”primitives 1908 a-c at the recipient device 201 b, which in turn maycause multiple “Confirm” primitives 1904 a-c or the aggregated “Confirm”primitive 1910 at the requestor 201 a. For example, a general contextoperation request primitive may generate multiple other primitivesbecause the general context operation request primitive may containmultiple specific context operations and each specific context operationmay lead to a separate set of other primitives (e.g., indication,response, and/or confirm). By way of another example, one contextmanagement message from the PD 201 a to the PD 201 b may cause multipleresponse messages back from the PD 201 b, which in turn may meanmultiple primitives.

Thus, as described above with reference to FIG. 20, a system may includea recipient peer device that includes a physical (PHY) layer, a mediumaccess control (MAC) layer above the PHY layer in a protocol stack, anda higher layer above the MAC layer in the protocol stack. At the MAClayer of the recipient peer device, a request from an originator peerdevice may be received. The request may be associated with contextinformation. As described above, the recipient peer device may generatea plurality of primitives, for instance which include a first primitive,in response to the request. The primitives may be associated withrespective context information. The recipient peer device may send theprimitives to the higher layer above the MAC layer. At the higher layer,the recipient device may generate a result associated with the request.Further, the recipient peer device may send responses associated witheach of the plurality of primitives to the originator peer device.

The disclosed primitives described above can be implemented in variouscontext management scenarios, some of which are presented below by wayof example and without limitation. In one example, referring to FIG. 21,a first PD 201 a measures its context information at its PHY layer 102,and reports the information to a second PD 201 b, which in turn notifiesits high layer 106. In another example, referring to FIG. 22 and FIG.19, the first PD 201 a decides to send a context notification to thesecond PD 201 b and the third PD 201 c.

Referring particularly to FIG. 21, at 2102, the recipient high layer 106sends the HLCM-SSUBSCRIBE.Request primitive to the recipient contextmanager 120 to subscribe to a particular context (e.g., link quality atthe originator PD 201 a). At 2104, in accordance with the illustratedexample, the recipient context manager 120 sends the HLCM-SUBSCRIBE.Confirm primitive to the recipient high layer 106. At 2106, theoriginator context manager 120 sends the PLCM-MEASURE.Request primitive,to the originator PHY layer 102, to measure a particular context (e.g.,link quality). At 2108, the originator PHY 102 sends thePLCM-MEASURE.Confirm primitive to the originator context manager 120. At2110, in accordance with the illustrated example, the originator contextmanager 120 decides to report such measured context to the recipient 201b by sending the MLCM-REPORT.Request primitive to the originator MAClayer 104. At 2112, the originator MAC layer 104 sends the ContextReport Request message over the air to the recipient MAC layer 104. At2114, the recipient MAC layer 104 sends the MLCM-REPORT.Indicationprimitive to the recipient context manager 120. At 2116, the recipientcontext manager 120 updates its context database accordingly. At 2118,the recipient context manager 120 decides to send theHLCM-NOTIFY.Request primitive to the recipient high layer 106, forexample, because the recipient high layer 106 creates the contextsubscription with the recipient context manager 120. At 2120, therecipient high layer 106 sends the HLCM-NOTIFY.Confirm primitive to therecipient context manager 120. At 2122, the recipient context manager120 sends the MLCM-REPORT.Response primitive to the recipient MAC layer104. At 2124, the recipient MAC layer 104 sends the Context ReportResponse over the air to the originator MAC layer 104. At 2126, theoriginator MAC layer 104 sends the MLCM-REPORT.Confirm primitive to theoriginator context manager 120.

Referring now to FIG. 22, at 2202, the originator context manager 120sends the MLCM.NOTIFY.Request primitive to the originator MAC layer 104to request that context information be changed. By way of example, alocation of the PD 201 a may have changed, and the request maybe sent sothat context information associated with the location is updated andprovided to other peer devices accordingly. This primitive may triggersteps 2204 and 2214, and one or more of the illustrated primitives. At2204, in accordance with the illustrated example, the originator 201 asends the Context Notify Request message to the recipient MAC layer 104of the second PD 201 b. At 2206, the recipient MAC layer 104 of thesecond PD 201 b sends the MLCM-NOTIFY.Indication primitive to itscontext manager 120. At 2208, the recipient context manager 120 of thesecond PD 201 b sends the MLCM-NOTIFY.Response primitive to its MAClayer 104. At 2210, the recipient MAC layer 104 of the second PD 201 bsends the Context Notify Response message to the originator MAC layer104 of the first PD 201 a. At 2212, the originator MAC layer 104 sendsthe MLCM-NOTIFY.Confirm primitive to the originator context manager 120.At 2214, the originator 201 a sends the Context Notify Request messageto the recipient MAC layer 104 of the third PD 201 c. At 2216, therecipient MAC layer 104 of the third PD 201 c sends theMLCM-NOTIFY.Indication primitive to its context manager 120. At 2218,the recipient context manager 120 of third PD 201 c sends theMLCM-NOTIFY.Response primitive to its MAC layer 104. At 2210, therecipient MAC layer 104 of the third PD 201 c sends the Context NotifyResponse message to the originator MAC layer of the first PD 201 a. At2211, the originator MAC layer 201 a sends the MLCM-NOTIFY.Confirmprimitive to the originator context manager 120.

Still referring to FIG. 22, in one embodiment, step 2214 can beperformed immediately after Step 2204. Further, in an exampleembodiment, step 2212 can be skipped and combined with step 2222. Inthis case, the originator MAC layer 104 may send one, for instance onlyone, MLCM-NOTIFY.Confirm primitive to the originator CM 120, whichcontains response information from both the second PD 201 b and thethird PD 201 c.

In accordance with another example embodiment, the HLCM SAP 122described above is leveraged as a user interface for users orapplications on a PD. The user interface can be used to preconfigure,access, and/or manage the described context management functions on thePD.

FIG. 23A is a diagram of an example machine-to machine (M2M) or Internetof Things (IoT) communication system 10 in which context management asdescribed herein may be implemented. Generally, M2M technologies providebuilding blocks for the IoT, and any M2M device, gateway or serviceplatform may be a component of the IoT as well as an IoT service layer,etc. Any of the peer devices illustrated in FIGS. 4-22 may comprise anode of a communication system such as the one illustrated in FIGS.23A-D.

As shown in FIG. 23A, the M2M/IoT communication system 10 includes acommunication network 12. The communication network 12 may be a fixednetwork or a wireless network (e.g., WLAN, cellular, or the like) or anetwork of heterogeneous networks. For example, the communicationnetwork 12 may comprise of multiple access networks that providescontent such as voice, data, video, messaging, broadcast, or the like tomultiple users. For example, the communication network 12 may employ oneor more channel access methods, such as code division multiple access(CDMA), time division multiple access (TDMA), frequency divisionmultiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA(SC-FDMA), and the like. Further, the communication network 12 maycomprise other networks such as a core network, the Internet, a sensornetwork, an industrial control network, a personal area network, a fusedpersonal network, a satellite network, a home network, or an enterprisenetwork for example.

As shown in FIG. 23A, the M2M/IoT/WoT communication system 10 mayinclude the Infrastructure Domain and the Field Domain. TheInfrastructure Domain refers to the network side of the end-to-end M2Mdeployment, and the Field Domain refers to the area networks, usuallybehind an M2M gateway. The Field Domain and Infrastructure Domain mayboth comprise a variety of different nodes (e.g., servers, gateways,devices, of the network). For example, the Field Domain may include M2Mgateways 14 and terminal devices 18. It will be appreciated that anynumber of M2M gateway devices 14 and M2M terminal devices 18 may beincluded in the M2M/IoT/WoT communication system 10 as desired. Each ofthe M2M gateway devices 14 and M2M terminal devices 18 are configured totransmit and receive signals via the communication network 12 or directradio link. A M2M gateway device 14 allows wireless M2M devices (e.g.cellular and non-cellular) as well as fixed network M2M devices (e.g.,PLC) to communicate either through operator networks, such as thecommunication network 12 or direct radio link. For example, the M2Mdevices 18 may collect data and send the data, via the communicationnetwork 12 or direct radio link, to an M2M application 20 or M2M devices18. The M2M devices 18 may also receive data from the M2M application 20or an M2M device 18. Further, data and signals may be sent to andreceived from the M2M application 20 via an M2M service layer 22, asdescribed below. M2M devices 18 and gateways 14 may communicate viavarious networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN,Bluetooth), direct radio link, and wireline for example. Exemplary M2Mdevices include, but are not limited to, tablets, smart phones, medicaldevices, temperature and weather monitors, connected cars, smart meters,game consoles personal digital assistants, health and fitness monitors,lights, thermostats, appliances, garage doors and other actuator-baseddevices, security devices, and smart outlets.

Referring to FIG. 23B, the illustrated M2M service layer 22 in the fielddomain provides services for the M2M application 20, M2M gateway devices14, and M2M terminal devices 18 and the communication network 12. Itwill be understood that the M2M service layer 22 may communicate withany number of M2M applications, M2M gateway devices 14, M2M terminaldevices 18, and communication networks 12 as desired. The M2M servicelayer 22 may be implemented by one or more servers, computers, or thelike. The M2M service layer 22 provides service capabilities that applyto M2M terminal devices 18, M2M gateway devices 14 and M2M applications20. The functions of the M2M service layer 22 may be implemented in avariety of ways, for example as a web server, in the cellular corenetwork, in the cloud, etc.

Similar to the illustrated M2M service layer 22, there is the M2Mservice layer 22′ in the Infrastructure Domain. M2M service layer 22′provides services for the M2M application 20′ and the underlyingcommunication network 12′ in the infrastructure domain. M2M servicelayer 22′ also provides services for the M2M gateway devices 14 and M2Mterminal devices 18 in the field domain. It will be understood that theM2M service layer 22′ may communicate with any number of M2Mapplications, M2M gateway devices and M2M terminal devices. The M2Mservice layer 22′ may interact with a service layer by a differentservice provider. The M2M service layer 22′ may be implemented by one ormore servers, computers, virtual machines (e.g., cloud/compute/storagefarms, etc.) or the like.

Still referring to FIG. 23B, the M2M service layer 22 and 22′ provide acore set of service delivery capabilities that diverse applications andverticals can leverage. These service capabilities enable M2Mapplications 20 and 20′ to interact with devices and perform functionssuch as data collection, data analysis, device management, security,billing, service/device discovery, etc. Essentially, these servicecapabilities free the applications of the burden of implementing thesefunctionalities, thus simplifying application development and reducingcost and time to market. The service layer 22 and 22′ also enables M2Mapplications 20 and 20′ to communicate through various networks 12 and12′ in connection with the services that the service layer 22 and 22′provide.

The M2M applications 20 and 20′ may include applications in variousindustries such as, without limitation, transportation, health andwellness, connected home, energy management, asset tracking, andsecurity and surveillance. As mentioned above, the M2M service layer,running across the devices, gateways, and other servers of the system,supports functions such as, for example, data collection, devicemanagement, security, billing, location tracking/geofencing,device/service discovery, and legacy systems integration, and providesthese functions as services to the M2M applications 20 and 20′.

Generally, a service layer (SL), such as the service layers 22 and 22′illustrated in FIGS. 23A and 23B, defines a software middleware layerthat supports value-added service capabilities through a set ofapplication programming interfaces (APIs) and underlying networkinginterfaces. Both the ETSI M2M and oneM2M architectures define a servicelayer. ETSI M2M's service layer is referred to as the Service CapabilityLayer (SCL). The SCL may be implemented in a variety of different nodesof the ETSI M2M architecture. For example, an instance of the servicelayer may be implemented within an M2M device (where it is referred toas a device SCL (DSCL)), a gateway (where it is referred to as a gatewaySCL (GSCL)) and/or a network node (where it is referred to as a networkSCL (NSCL)). The oneM2M service layer supports a set of Common ServiceFunctions (CSFs) (i.e. service capabilities). An instantiation of a setof one or more particular types of CSFs is referred to as a CommonServices Entity (CSE), which can be hosted on different types of networknodes (e.g. infrastructure node, middle node, application-specificnode). The Third Generation Partnership Project (3GPP) has also definedan architecture for machine-type communications (MTC). In thatarchitecture, the service layer, and the service capabilities itprovides, are implemented as part of a Service Capability Server (SCS).Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture,in a Service Capability Server (SCS) of the 3GPP MTC architecture, in aCSF or CSE of the oneM2M architecture, or in some other node of anetwork, an instance of the service layer may be implemented in alogical entity (e.g., software, computer-executable instructions, andthe like) executing either on one or more standalone nodes in thenetwork, including servers, computers, and other computing devices ornodes, or as part of one or more existing nodes. As an example, aninstance of a service layer or component thereof may be implemented inthe form of software running on a network node (e.g., server, computer,gateway, device, or the like) having the general architectureillustrated in FIG. 23C or 23D described below.

Further, the methods and functionalities described herein may beimplemented as part of an M2M network that uses a Service OrientedArchitecture (SOA) and/or a resource-oriented architecture (ROA) toaccess services, such as the above-described context management forexample.

FIG. 23C is a block diagram of an example hardware/software architectureof a node of a network, such as one of the peer devices illustrated inFIGS. 4-22, which may operate as an M2M server, gateway, device, orother node in an M2M network such as that illustrated in FIGS. 23A and23B. As shown in FIG. 23C, the node 30 may include a processor 32, atransceiver 34, a transmit/receive element 36, a speaker/microphone 38,a keypad 40, a display/touchpad 42, non-removable memory 44, removablememory 46, a power source 48, a global positioning system (GPS) chipset50, and other peripherals 52. The node 30 may also include communicationcircuitry, such as a transceiver 34 and a transmit/receive element 36.It will be appreciated that the node 30 may include any sub-combinationof the foregoing elements while remaining consistent with an embodiment.This node may be a node that implements the context managementfunctionality described herein.

The processor 32 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 32 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the node 30 to operate in a wirelessenvironment. The processor 32 may be coupled to the transceiver 34,which may be coupled to the transmit/receive element 36. While FIG. 23Cdepicts the processor 32 and the transceiver 34 as separate components,it will be appreciated that the processor 32 and the transceiver 34 maybe integrated together in an electronic package or chip. The processor32 may perform application-layer programs (e.g., browsers) and/or radioaccess-layer (RAN) programs and/or communications. The processor 32 mayperform security operations such as authentication, security keyagreement, and/or cryptographic operations, such as at the access-layerand/or application layer for example.

As shown in FIG. 23C, the processor 32 is coupled to its communicationcircuitry (e.g., transceiver 34 and transmit/receive element 36). Theprocessor 32, through the execution of computer executable instructions,may control the communication circuitry in order to cause the node 30 tocommunicate with other nodes via the network to which it is connected.In particular, the processor 32 may control the communication circuitryin order to perform the transmitting and receiving steps describedherein (e.g., in FIGS. 4-22) and in the claims. While FIG. 23C depictsthe processor 32 and the transceiver 34 as separate components, it willbe appreciated that the processor 32 and the transceiver 34 may beintegrated together in an electronic package or chip.

The transmit/receive element 36 may be configured to transmit signalsto, or receive signals from, other nodes, including M2M servers,gateways, devices, and the like. For example, in an embodiment, thetransmit/receive element 36 may be an antenna configured to transmitand/or receive RF signals. The transmit/receive element 36 may supportvarious networks and air interfaces, such as WLAN, WPAN, cellular, andthe like. In an embodiment, the transmit/receive element 36 may be anemitter/detector configured to transmit and/or receive IR, UV, orvisible light signals, for example. In yet another embodiment, thetransmit/receive element 36 may be configured to transmit and receiveboth RF and light signals. It will be appreciated that thetransmit/receive element 36 may be configured to transmit and/or receiveany combination of wireless or wired signals.

In addition, although the transmit/receive element 36 is depicted inFIG. 23C as a single element, the node 30 may include any number oftransmit/receive elements 36. More specifically, the node 30 may employMIMO technology. Thus, in an embodiment, the node 30 may include two ormore transmit/receive elements 36 (e.g., multiple antennas) fortransmitting and receiving wireless signals.

The transceiver 34 may be configured to modulate the signals that are tobe transmitted by the transmit/receive element 36 and to demodulate thesignals that are received by the transmit/receive element 36. As notedabove, the node 30 may have multi-mode capabilities. Thus, thetransceiver 34 may include multiple transceivers for enabling the node30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 32 may access information from, and store data in, anytype of suitable memory, such as the non-removable memory 44 and/or theremovable memory 46. The non-removable memory 44 may includerandom-access memory (RAM), read-only memory (ROM), a hard disk, or anyother type of memory storage device. The removable memory 46 may includea subscriber identity module (SIM) card, a memory stick, a securedigital (SD) memory card, and the like. In other embodiments, theprocessor 32 may access information from, and store data in, memory thatis not physically located on the node 30, such as on a server or a homecomputer. The processor 32 may be configured to control lightingpatterns, images, or colors on the display or indicators 42 to reflectthe status of a peer device, or other underlying networks, applications,or other services in communication with the peer device. The processor32 may receive power from the power source 48, and may be configured todistribute and/or control the power to the other components in the node30. The power source 48 may be any suitable device for powering the node30. For example, the power source 48 may include one or more dry cellbatteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metalhydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells,and the like.

The processor 32 may also be coupled to the GPS chipset 50, which isconfigured to provide location information (e.g., longitude andlatitude) regarding the current location of the node 30. It will beappreciated that the node 30 may acquire location information by way ofany suitable location-determination method while remaining consistentwith an embodiment.

The processor 32 may further be coupled to other peripherals 52, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 52 may include anaccelerometer, an e-compass, a satellite transceiver, a sensor, adigital camera (for photographs or video), a universal serial bus (USB)port, a vibration device, a television transceiver, a hands freeheadset, a Bluetooth® module, a frequency modulated (FM) radio unit, adigital music player, a media player, a video game player module, anInternet browser, and the like.

FIG. 23D is a block diagram of an exemplary computing system 90 whichmay also be used to implement one or more nodes of a network, such asthe nodes illustrated in FIGS. 4-22, which may operates as an M2Mserver, gateway, device, or other node in an M2M network such as thatillustrated in FIGS. 23A and 23B. Computing system 90 may comprise acomputer or server and may be controlled primarily by computer readableinstructions, which may be in the form of software, wherever, or bywhatever means such software is stored or accessed. Such computerreadable instructions may be executed within central processing unit(CPU) 91 to cause computing system 90 to do work. In many knownworkstations, servers, and personal computers, central processing unit91 is implemented by a single-chip CPU called a microprocessor. In othermachines, the central processing unit 91 may comprise multipleprocessors. Coprocessor 81 is an optional processor, distinct from mainCPU 91, which performs additional functions or assists CPU 91. CPU 91and/or coprocessor 81 may receive, generate, and process data related tothe disclosed systems and methods for E2E M2M service layer sessions,such as receiving session credentials or authenticating based on sessioncredentials.

In operation, CPU 91 fetches, decodes, and executes instructions, andtransfers information to and from other resources via the computer'smain data-transfer path, system bus 80. Such a system bus connects thecomponents in computing system 90 and defines the medium for dataexchange. System bus 80 typically includes data lines for sending data,address lines for sending addresses, and control lines for sendinginterrupts and for operating the system bus. An example of such a systembus 80 is the PCI (Peripheral Component Interconnect) bus.

Memory devices coupled to system bus 80 include random access memory(RAM) 82 and read only memory (ROM) 93. Such memories include circuitrythat allows information to be stored and retrieved. ROMs 93 generallycontain stored data that cannot easily be modified. Data stored in RAM82 can be read or changed by CPU 91 or other hardware devices. Access toRAM 82 and/or ROM 93 may be controlled by memory controller 92. Memorycontroller 92 may provide an address translation function thattranslates virtual addresses into physical addresses as instructions areexecuted. Memory controller 92 may also provide a memory protectionfunction that isolates processes within the system and isolates systemprocesses from user processes. Thus, a program running in a first modecan access only memory mapped by its own process virtual address space;it cannot access memory within another process's virtual address spaceunless memory sharing between the processes has been set up.

In addition, computing system 90 may contain peripherals controller 83responsible for communicating instructions from CPU 91 to peripherals,such as printer 94, keyboard 84, mouse 95, and disk drive 85.

Display 86, which is controlled by display controller 96, is used todisplay visual output generated by computing system 90. Such visualoutput may include text, graphics, animated graphics, and video. Display86 may be implemented with a CRT-based video display, an LCD-basedflat-panel display, gas plasma-based flat-panel display, or atouch-panel. Display controller 96 includes electronic componentsrequired to generate a video signal that is sent to display 86.

Further, computing system 90 may contain communication circuitry, suchas for example a network adaptor 97 that may be used to connectcomputing system 90 to an external communications network, such asnetwork 12 of FIG. 23A and FIG. 23B, to enable the computing system 90to communicate with other nodes of the network. The communicationcircuitry, alone or in combination with the CPU 91, may be used toperform the transmitting and receiving steps described herein (e.g., inFIGS. 4-22) and in the claims.

It will be understood that any of the methods and processes describedherein may be embodied in the form of computer executable instructions(i.e., program code) stored on a computer-readable storage medium whichinstructions, when executed by a machine, such as a computer, server,M2M terminal device, M2M gateway device, peer device, or the like,perform and/or implement the systems, methods and processes describedherein. Specifically, any of the steps, operations or functionsdescribed above may be implemented in the form of such computerexecutable instructions. Computer readable storage media include bothvolatile and nonvolatile, removable and non-removable media implementedin any method or technology for storage of information, but suchcomputer readable storage media do not includes signals. Computerreadable storage media include, but are not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other physical medium which can be used to store the desiredinformation and which can be accessed by a computer.

In describing preferred embodiments of the subject matter of the presentdisclosure, as illustrated in the Figures, specific terminology isemployed for the sake of clarity. The claimed subject matter, however,is not intended to be limited to the specific terminology so selected,and it is to be understood that each specific element includes alltechnical equivalents that operate in a similar manner to accomplish asimilar purpose.

What is claimed:
 1. At a first peer device comprising a processor, amemory, and communication circuitry, the first peer device beingconnected to a communications network via its communication circuitry,the first peer device further comprising computer-executableinstructions stored in the memory of the first peer device which, whenexecuted by the processor of the first peer device, cause the first peerdevice to: at a higher layer above a medium access control (MAC) layerin a protocol stack of the first peer device, initiate a requestassociated with context information; send, via a context manger, a firstprimitive associated with the request to the MAC layer; and in responseto the first primitive, receive a second primitive at the higher layer,the second primitive indicating a result associated with the request. 2.The first peer device of claim 1, wherein the computer-executableinstructions further cause the first peer device to: based on therequest, send a context request to a MAC layer of a second peer devicein peer-to-peer communications with the first peer device.
 3. The firstpeer device of claim 1, wherein the context request causes the MAC layerof the second peer device to send a third primitive to a higher layer ofthe second peer device, such that the higher layer of the second peerdevice produces the result indicated by the second primitive.
 4. Thefirst peer device as recited in claim 1, wherein the first and secondprimitives are associated with at least one of a subscription request, areport request, a notification request, or a delete request.
 5. Thefirst peer device as recited in claim 1, wherein the computer-executableinstructions further cause the first peer device to: based on therequest, send a context request to a MAC layer of a plurality of peerdevices, such that the plurality of peer devices can each respond to thecontext request.
 6. The first peer device as recited in claim 5, whereinthe computer-executable instructions further cause the first peer deviceto: receive a plurality of responses associated with the request fromthe plurality of peer devices; and aggregate the plurality of responsesinto an aggregated primitive.
 7. In a system comprising a first peerdevice that includes a physical (PHY) layer, a medium access control(MAC) layer above the PHY layer in a protocol stack, and a higher layerabove the MAC layer in the protocol stack, a method comprising: at thehigher layer, initiating a request associated with context information;sending, via a context manger, a first primitive associated with therequest to the MAC layer; and in response to the primitive, receiving asecond primitive at the higher layer, the second primitive indicating aresult associated with the request.
 8. The method as recited in claim 7,the method further comprising: based on the request, sending a contextrequest to a MAC layer of a second peer device in peer-to-peercommunications with the first peer device.
 9. The method as recited inclaim 8, wherein the context request causes the MAC layer of the secondpeer device to send a third primitive to a higher layer of the secondpeer device, such that the second peer device produces the resultindicated by the second primitive.
 10. The method as recited in claim 7,wherein the first and second primitives are associated with at least oneof a subscription request, a report request, a notification request, ora delete request.
 11. At a recipient peer device comprising a processor,a memory, and communication circuitry, the first peer device beingconnected to a communications network via its communication circuitry,the recipient peer device further comprising computer-executableinstructions stored in the memory of the recipient peer device which,when executed by the processor of the recipient peer device, cause therecipient peer device to: at a medium access control (MAC) layer of therecipient peer device, receive a request from an originator peer device,the request associated with context information; generate a firstprimitive associated with the request and the context information; sendthe first primitive to a layer above the MAC layer; and at the layerabove the MAC layer, generate a result associated with the request. 12.The recipient peer device of claim 11, wherein the computer-executableinstructions further cause the recipient peer device to: generate asecond primitive indicative of the result; and send the second primitivefrom the layer above the MAC layer to the MAC layer.
 13. The recipientpeer device of claim 12, wherein the computer-executable instructionsfurther cause the recipient peer device to: at the MAC layer, send aresponse to the originator peer device, the response indicative of theresult.
 14. The originator peer device as recited in claim 12, whereinthe first and second primitives are associated with at least one of asubscription request, a report request, a notification request, or adelete request.
 15. In a system comprising a recipient peer device thatincludes a physical (PHY) layer, a medium access control (MAC) layerabove the PHY layer in a protocol stack, and a higher layer above theMAC layer in the protocol stack, a method comprising: at the MAC layerof the recipient peer device, receiving a request from an originatorpeer device, the request associated with context information; generatinga first primitive associated with the request and the contextinformation; sending the first primitive to the higher layer above theMAC layer; and at the higher layer above the MAC layer, generating aresult associated with the request.
 16. The method as recited in claim15, the method further comprising: generating a second primitiveindicative of the result; and sending the second primitive from thehigher layer to the MAC layer.
 17. The method as recited in claim 16,the method further comprising: at the MAC layer, sending a response tothe originator peer device, the response indicative of the result. 18.The method as recited in claim 16, wherein the first and secondprimitives are associated with at least one of a subscription request, areport request, a notification request, or a delete request.
 19. Themethod as recited in claim 15, in response to the request, generating aplurality of primitives, each of the plurality of primitives associatedwith respective context information; and sending responses associatedwith each of the plurality of primitives to the originator peer device.